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ABSTRACT 



A system with a network interconnecting a server and a 
plurality of user stations. The system provides the capability 
of allowing an administrator to configure a user application 
by running the application directly in the context of a user 
or user group, rather than in the context of the administrator. 
That is, the configuration of the application is performed by 
executing the application, configuring the application using 
the options provided by the application for that purpose, and 
then saving the configuration as if the actual user or group 
were executing the application. 

7 Claims, 22 Drawing Sheets 
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CLIENT — SERVER SYSTEM WITH 
CENTRAL APPLICATION MANAGEMENT 
ALLOWING AN ADMINISTRATOR TO 
CONFIGURE END USER APPLICATIONS BY 
EXECUTING THEM IN THE CONTEXT OF 
USERS AND GROUPS 

TECHNICAL FIELD 

The invention relates generally to the fields of personal 
computing and networking. Specifically, it relates to the new 
and evolving field of network computing, in which desktop 
computer users use a personal computer, possibly diskless, 
connected to a network such as a corporate intranet, the 
Internet, or to an network or Internet Service Provider (ISP) 
to gain access to applications which are then executed on the 
desktop computer. More specifically, the invention relates to 
server-based storage of software preferences (configuration 
data) for software retrieved from a server and executing at 
the desktop computer. 

BACKGROUND OF THE INVENTION 

The field of network computers is presently in its infancy. 
However, it is expected to evolve rapidly, especially in the 
corporate environment, for a number of reasons. The expec- 
tation is that as companies and possibly individual users 
reach hardware and software upgrade points, it will be more 
efficient and less expensive to move to this new field, rather 
than upgrade in the traditional way with disk equipped 
computers and locally stored and administered software 
applications. For example, in the corporate environment, a 
user can be connected to a corporate intranet, using, for 
example, the TCP/IP and HTTP protocols of the Internet, 
and download software applications as they are needed 
directly from a network server to the desktop computer. An 
application is executed on the desktop in the traditional 
manner by the user to perform useful work. An advantage of 
this configuration is that network computers are substan- 
tially less expensive than traditional disk equipped comput- 
ers. It might also cost less to purchase the required number 
of software licenses for users, rather than purchase indi- 
vidual copies of software for each user. Certainly, the 
software administration problems that attend large numbers 
of corporate users will be substantially reduced. At the 
present time, each user of a disk equipped computer or 
workstation often is effectively his or her own system 
administrator, a role that often consumes excessive 
resources due to lack of expertise. It is expected to be a great 
advantage to eliminate this problem by effectively offloading 
the problem to a small number of server administration 
experts, rather than having many users struggle with the 
problems of software installation, upgrades and computer 
administration. 

As mentioned above, this vision of the future of personal 
computing is presently in its infancy. As a result, there are 
presently many problems and deficiencies with existing 
systems. 

Typically, in network computer systems, an administrator 
creates user profiles that are stored on a network server. The 
profiles may contain different types of information, such as 
user desktop preferences and user permissions for access to 
different software applications that might reside on the 
server. When a user logs onto the system, the user identifies 
him or herself to the server, the server locates the profile for 
the user and transmits it to the user computer where it is used 
to configure the computer and generate a desktop. The 
desktop might include a number of icons representing appli- 
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cations to which the user presumably has access. The profile 
likely also contains other attributes of the computer and 
desktop, such as for example, the background color of the 
desktop, or character fonts and point sizes used on the 

5 desktop, or data file search paths, etc. that are unique to the 
user, liie profiles may be user modifiable or non-modifiable. 

In an environment in which users can modify their own 
profiles, a modified profile is uploaded back to the server at 
log-off time, where it is stored for retrieval the next time the 

10 user logs-on. In some prior art systems, to the best of our 
knowledge, the users can generate on their desktops any 
configuration of application icons they wish, whether or not 
they exist on the server, and whether or not a user actually 
has access permission to an application on the server. The 

15 Lotus Workplace Desktop (previously called Kona Desktop) 
system is an example of this type of operation. In other 
systems, the server presents a list to the user of all applica- 
tions that the server has, from which the user can pick. In this 
case, there is no guarantee that the user actually has access 

20 permission to an application that is selected from the list for 
inclusion on the desktop. The Sun Hot Java Views system is 
an example of this type of system. In other words, the prior 
art systems do not correlate between what the user can 
configure for the set of desktop application icons and 

25 applications to which the user actually has permission 
access. In such a case, when the user clicks on a icon to 
execute an application, an error message may occur (such as 
an unauthorized access message) if access permission is not 
present, or in a worse case, the user's computer may crash. 

30 Another limitation with existing art is that a fiat data 
structure is used to model users, user groups, terminals and 
groups of terminals. Modeled after a common scheme for 
managing user access to computer resources, known net- 
work computer implementations (e.g., Lotus Administration 

35 Facility for Desktops, Microsoft Windows NT Profiles and 
Policies, and Sun Hot Java Views) implement a flat "groups" 
structure on the server for managing software preferences 
(or attributes) in various contexts. A "context", as used here, 
refers to an individual user, user group, terminal, or terminal 

40 group. Any grouping structure for managing software pref- 
erences on the server allows an administrator to define 
preference attributes for different groups of users as well as 
for individual users. However, flat systems are inflexible in 
many environments, especially in environments having 

45 large numbers of users. It is desirable to provide an admin- 
istrative tool supporting the organization of preference infor- 
mation into a hierarchical structure. 

Another limitation with existing systems is that they are 
limited in the ways that administrators and users have to 

50 perform user configuration of workstation desktops. For 
example, administrators are presendy required to configure 
user preferences using configuration programs that are sepa- 
rate from, but associated with, a user application. It is 
desirable to allow vendors to provide only a single applica- 

55 tion. To require only an end user application from a vendor 
necessitates that the central management facility be able to 
execute the end user application in a context of a user or user 
group. The prior art does not allow this administrative 
flexibility of operation. In other words, in the prior art, to the 

60 best of our knowledge, an administrator does not have the 
ability to run a user application in the context of a user to set 
preferences for that user and application. Further, in the art, 
an administrator cannot run a user application to set pref- 
erences in the context of a group of users. 

65 Still another limitation in the prior art known to the 
inventors is the manner in which the prior art partitions 
server permanent storage space to guarantee that a unique 
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space is reserved for storing user preferences related to the under, the application needs to be relaunched to load con- 
different applications on the server. To the knowledge of the figuration information for the new context. The process of 
inventors, the problem of preventing collisions in the storage relaunching software each time a context is changed is time 
of preference information for different applications in consuming and inconvenient for an administrator, especially 
object-oriented systems, in which an object can be queried 5 in systems with many users. In such systems, it is expected 
for its fully qualified class name which uniquely identifies that an administrator will change contexts many times while 
and differentiates it from other classes, is solved by having configuring an application, 
a first central authority assign a unique designation that SUMMARY OF THE INVENTION 
applies to a vendor and by then having a second authority at __ , , , . , 
J . j j • i . .l c * The system described herein provides a common reposi- 
to vendor assign a second designation relative to the first 10 for * onfi tion MoTm ^ n for ^ ^ applets 7 a a 

designation for each vendor application. For c xample, ven- ^.server, environment. This is referred to as client profile 

dor A might be assigned the designation vendor by the first managemem . The syslem allows users to roam, that is, to 

authority and that designation is guaranteed to be unique b . from any m the system at any time and have 

within the architecture for which the first authonty is acting. it configured automatically at run time according to the 

The second authority at vendor A then assigns the second 15 preferences stored for the user at the server. The preferred 

designation for each of its applications within that architec- embodiment is a Java (Java is a Trademark of Sun, Inc.) 

ture. For example, one of vendor A*s applications might be based system and the client computers use a web browser 

designated-vendorA-Appl; another might be designated interface arranged to execute Java applications. Thus, in the 

vendor A. App2. The art maps the unique designation for preferred embodiment, user applets and the desktop applet 

each application in a system to a location in permanent 2 o are assumed to be Java applets. However, it is not intended 

storage of the system to guarantee that preference data for to limit the invention to a Java environment. Preferences for 

the different applications do not collide in storage. An the locally stored applications might be stored locally in the 

application, when running, informs the network computer traditional manner, while preferences for the server-based 

server of its unique storage location and it is the responsi- applets might be handled in the way described herein, 

bility of the server to partition an area at the starting location 25 The invention provides the capability of allowing an 

according to a context (user, user group, terminal or terminal administrator to configure a user application by running the 

group) for storing preference information so as not to collide application directly in the context of a user or user group, 

with preference information in a different context. Clearly, rather than in the context of the administrator. That is, the 

this manner of administering storage space is awkward and configuration of the application is performed by executing 

undesirable. It is desirable to devise a method to automati- 30 the application, configuring the application using the options 

cally generate unique storage locations for storing prefer- provided by the application for that purpose, and then saving 

ence information for the afore mentioned object-oriented the configuration as if the actual user or group were execut- 

applications, without resorting to the requirement of having ing the application. 

central authorities assign unique designations for the pur- j D tne pre f e rred embodiment, the system comprising a 

pose of preventing collisions in the storage of preference 35 network which interconnect a server and a plurality of user 

information and without coding storage location information stations. The server stores a plurality of user applications for 

into an application. downloading to user. A profile manager is provided at an 

Still another limitation in the art lies in the lack of any administrators station. The profile manager is arranged to 

provision to migrate existing applications and hardware into execute a separate configuration application for a first end 

the new environment of the centrally managed network 40 user application, whereby the administrator can specify 

computing world without requiring changes to the existing configuration preferences for the first end user application in 

hardware and applications. Existing hardware, a terminal for the context of different groups and subgroups of system 

example, in a networked environment, gets its configuration US ers and store the configuration preferences for the first end 

information at boot-up time from a file in a specific format user application on the server. The profile manager is further 

located on a server. The terminal is programmed to know 45 arranged to execute a second end user application in the 

how to access its configuration file. The terminal uses a context of different groups and subgroups of users to specify 

unique identifier to access the file from the server. The configuration preferences for the second end user applica- 

unique identifier is often the media access control (MAC) tion in the context of different groups and subgroups. This is 

address of the terminal However, in a new centrally man- done by executing the second end user application at the 

aged environment involving protocols and API's that are 50 administrator's station in a selected user or group context 

different from that to which the terminal is designed, the and then storing the configuration preferences for the second 

terminal cannot access preference information in the new end user application on the server, 

environment, the terminal can only access its configuration Thus, me invention allows administrators to configure an 

file in the way for which it is designed. This is a serious e nd user application directly by effectively running the end 

problem, because there are many such existing devices in 55 user application while posing as a user or as a user group. An 

use. The inability to use them in new systems impedes added advantage of this invention is that the administrator 

substantially the incentives for users to migrate to the new can mri user applications and see the same screens that a user " 

systems. sees This aids the administrator in diagnosing user problems 

Still another limitation in the prior art concerns the by running the user application in the context of a user with 

interface between an administrator and the configuration 60 the user configuration in place, rather the administrator's 

management system. When configuring software within an configuration. 

administration facility to configure preference information nFSCRlPTlfiiM OF thf HR AWTNfi 

for various users and user groups, and terminals and terminal BRIEF DESCRIPTION OF THE DRAWING 

groups, the administration software launches in the context In the Drawing, 

(user, user group, terminal or terminal group) set by the 65 FIG. 1 shows an illustrative network and user stations, 

Administrator who is running the facility. When the Admin- including an administrator's station, in which the invention 

istrator changes the context that the application is running might be practiced; 
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FIG. 2 shows an illustrative block diagram form of the 
administrator's station in communication with a server, and 
components of the administrator's station and the server for 
providing the central profile management and preference 
administration; 

FIG. 3 shows one illustrative hierarchical organization of 
user groups and users of a system. The illustrative hierar- 
chical organization might also contain individual terminals 
and terminal groups; however, these are omitted for sim- 
plicity; 

FIG. 4 shows one illustrative listing of individual users 
and the group priority order that is used to determine a set 
of preferences from the hierarchical organization of FIG. 3 
that apply to a user and a specific application executed by the 
user; 

FIG. 5 shows a more detailed view of the administrator's 
station and server of FIG. 2; 

FIG. 6 shows an illustrative view of the software objects 
at a user's terminal, including a user application and the API 
between the application and other components, that coop- 
erate to establish the user preferences during execution of 
the application as the user's terminal; 

FIGS. 7 through 8 show illustrative operations at both a 
user's terminal and a server for user log-on and initially 
establishing the user's desktop, including desktop 
preferences, at the user terminal; 

FIGS. 9 through 11 show illustrative operations at both an 
administrator's terminal and a server for administrator user 
log-on, establishment of the administrator's desktop, and, by 
way of example, the selection of an application and a context 
for configuration; the example also illustrates a context 
change during configuration the user's desktop and the 
resulting operations; and 

FIGS. 12 through 24 show a variety of actual adminis- 
trator screen snapshots in various phases of application 
administration, including building of a hierarchy of which 
FIG. 3 is a representation of an example of, the creation and 
deletion of users, etc. the establishment of application pref- 
erences for applications, and context changes during pref- 
erence establishment. 

DETAILED DESCRIPTION 

The system described herein provides a common reposi- 
tory for configuration information for all users and applets in 
a client-server environment. This is referred to as client 
profile management. The system allows users to roam, that 
is, to log-in from any computer in the system at any time and 
have it configured automatically at run time according to the 
preferences stored at the server. The preferred embodiment 
is a Java (Java is a Trademark of Sun, Inc.) based system and 
the client computers use a web browser interface arranged to 
execute Java programs. 

The terms "applet" and "servlel" are established terms in 
the Java programming language art and will be used herein, 
since the terms have meaning to those skilled in this art, 
"Applet" refers to an independent software module that runs 
within a Java enabled web browser. Servlet refers to a 
software module that resides on a Java enabled web server. 
It is to be understood that the use of the terms "applet" and 
"servlet" herein is not intended to limit the invention in any 
way. For clarification, the phrase "configuration applet" is 
used herein to refer to a software module used to configure 
preferences for an end user software application such as a 
word processor, a database manager, etc. Since software 
applications are also "applets" in the Java environment, the 
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phrase "user applet" or just "applet" is used herein to refer 
to an end user application. 

In the preferred embodiment, user applets and the desktop 
applet are assumed to be Java applets. However, it is 

5 understood that the invention is not limited to a Java 
environment. The invention can be used in any client-server 
system. For example, if desired, the system could be 
designed to use proprietary communication protocols and 
applications written and compiled in any desired program- 

10 ming language. Further, even in the preferred Java based 
environment, disk-based computers might access some 
applications locally, and other applets from the server. 
Preferences for the locally stored applications might be 
stored locally in the traditional manner, while preferences 

15 for the server-based applets might be bandied in the way 
described herein. Preferably, however, preferences for 
locally stored applications are stored on the server using the 
Profile Management Properties API in addition to the pref- 
erences for server based applets described herein. 

20 A simple Application Program Interface (API) allows 
applets written to the API to easily store and retrieve 
preference data when the applet is executed by a user or 
administrator. Applet permissions and user preferences can 
be defined based on group memberships and individual 

25 identity. 

Client profile management includes the following services: 
Log-on support — mapping to a user profile; 
User support — the administrative ability to create user 
3Q identifications and provide services and preferences 
directly to users; 
User groups support — the administrative ability to create 
hierarchical groups of users and provide services and 
preferences based on group memberships; 
35 User applet context transparency — automatic determina- 
tion of the context of user applet execution. That is, the 
determination of the user and/or group profiles that 
apply to a user applet execution and the automatic 
establishment of the profile environment; 
40 User applet preferences repository — context-sensitive 
server storage for user applet configuration data; 
Dynamic user applet preferences inheritance. — 
hierarchical load-time coalescence of user applet pref- 
erences via the object-oriented principal of inheritance; 
45 and 

User applet access control — control of user applet execu- 
tion based on group default membership privileges. 
The administrator can override default group privileges 
and permit or deny additional access privileges for 
50 individual users. 

Profile management provides a framework through which 
these tasks are performed. Some tasks are supported by 
profile management directly, e.g. user/group management, 
applet lists, context switching, preference inheritance, etc., 
55 while configuration services specific to user applets are 
usually supported by separate configuration applets invoked 
by a system administrator within the client profile manage- 
ment environment. Some end user applets might provide the 
configuration capability as part of the end user applet. If this 
60 is the case, the administrator can run the end user applet (as 
opposed to a separate configuration applet) in the context of 
individual users and groups to set the configuration prefer- 
ences for those users and groups. 

FIG. 1 shows one high level view of an intended envi- 
65 ronment for practicing the invention. A network 100 is 
provided for interconnecting a plurality of user stations, 
such as desktop personal computers 102, mobile laptop 
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computers 104, workstations 106 (e.g., RISC computers), an 
administrator's station 108 and a server 110. In one 
embodiment, network 100 might be a local area network. In 
another embodiment, network 100 might include wide area 
networking for entities such as corporations that have geo- 5 
graphically displaced sites that are still included within the 
system. There is no intent to limit the environment in which 
the invention might be practiced; indeed, a network of any 
type that interconnects many types of stations is envisioned. 

A high-level diagram of the profile management admin- 
istrative operating environment is shown in FIG. 2. An 
administrator client network computer 200 is represented on 
the left of the Fig. and a server 202 for the system is on the 
right. The client and server communicate via a network 
represented as 203. The particular example of FIG. 2 
assumes that the client computer is a system administrator's 15 
computer. 

Profile manager 206 on the client side allows the admin- 
istrator to configure user applet preferences at both user and 
group levels. The administrator can create new users and 
group hierarchies, add users to different groups, specify 20 
applet permissions for each group and for individual users. 
And the administrator can configure applets in the context of 
an individual user or a group. The administrator can add, 
delete and reset passwords for users. Profile management 
support is transparent to the general user. The administrator 25 
can invoke the profile manager 206 in the context of any user 
or group. Only the administrator can change from his/her 
context to administer clients (users) and groups. The server 
will not allow a user without administrative authority to 
switch context. When a request comes into the server, it will 30 
query the authenticated ID of the user trying to access this 
function. If the user does not possess administrative 
authority, (i.e., is not a member of the AllUsers.Adminis- 
trator group), the Profile Manager Servlet 214 will reject the 
request. 35 

Profile manager 206 invokes other applets, such as 
applet 1 (208), as shown in FIG. 2. In this example, appletl 
might be the administrative applet for configuring prefer- 
ences related to user desktops. Or appletl could be a 
configuration utility related to an end user applet, such as 40 
editors, word processors, databases, etc. It is preferred, but 
not required, that configuration applets such as 208 exist as 
modules separate from their corresponding user applets. In 
the context of FIG. 2, Appletl is typically a configuration 
applet for a user applet; the administrator runs the configu- 45 
ration applet appletl under a group context to set group 
preference and permission defaults, or in a user context to 
customize user applet configurations for an individual. By 
implementing appletl as a module separate from its user 
applet, performance is enhanced, since the configuration 50 
appletl will likely be small compared to the user applet. 
Also, separate configuration applets allow the administrator 
to control the end users ability to configure the user applet. 

Traditional stand-alone computers store user applet con- 
figuration information locally in association with its the user 55 
applet. Traditional stand-alone Java based computers store 
user applet configuration information using the format pro- 
vided by the java.u til. Properties class. Both arrangements 
require that the user applet specify the name of a local file 
in which to store configuration information related to the 60 
user applet. In other words, a relationship is required 
between the computer and the user applet loaded on it. 
Profile management as described herein provides the famil- 
iar capabilities of a real java.util. Properties object plus 
additional facilities supporting user-roaming capabilities 65 
and seamless pluggability into a powerful administrative 
framework (the Profile Manager). 
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ProfileManagementProperties P 210 is a properties object 
for appletl and provides an API between Appletl and the 
server that allows the server to determine where to store 
configuration information for appletl in the context of users 
and groups. The ProfileManagementProperties object class 
provides all of the functionality of the java.util.properties 
class with the further ability to provide create, save, and 
retrieve the configuration information for software from 
permanent storage. Storing such information in a central 
location makes management of user and group configura- 
tions possible. When a user is in the role of administrator, 
ProfileManagementProperties 210 allows the administrator 
to configure the user applet corresponding to configuration 
appletl, or to configure appletl if appletl is an end user 
applet, and store the configuration information in the proper 
place on the server in the proper context. This allows the 
establishment of a relationship between the user applet and 
the user, rather than between user applet and computer as in 
traditional systems. ProfileManagementProperties 210 is an 
extension of the java.util.Properties class. The extension 
allows the key/value pairs of preference information of a 
Properties object to be associated with a key, as opposed to 
a stream, as with java.util.Properties. This, in turn, allows 
application developers to use the key to specify a unique 
location relative to a context for preference information, 
rather than a file name and path. ProfileManagementProp- 
erties 210 determines the key automatically. The generation 
of the key is discussed more in connection with FIG.'s 8 and 
9. By modeling ProfileManagementProperties 210 after the 
java.util.Properties class, the system can take advantage of 
preference inheritance through recursive class-default evalu- 
ation. Thus, this extended class provides a "group default" 
capability by accumulating preferences starting at a current 
context, as discussed with respect to FIG. 3, and traversing 
up the contextual hierarchy for defaults. 

Server 202 includes a database 212 that stores user data 
and group data, such as user and group preferences and user 
applet access permissions. Webserver 218 represents a typi- 
cal web server with support for Java applets. Profile Man- 
ager servlet 214 maps user and group identifications to 
preference data. It also maintains an access control list to 
manage user access to applications on the server. 

User and group preferences are stored as a tree hierarchy, 
as shown in FIG. 3. All users of the system automatically 
belong to the top group AllUsers. All users belong to the 
All Users group; this group contains the default preferences 
for some or all user applets on the server. In FIG. 3, it is 
assumed that the server contains at least three user applets, 
identified as App3, App4 and App5. As indicated in the 
AllUsers group, the default background (BG) for App3 is 
BG=blue. Other illustrative preferences labeled as x, y and 
z are shown to have the default values of 1, 2 and 3 
respectively. The terms x, y and z are intended to represent 
any desired preference and the values 1, 2 and 3 are arbitrary 
and used merely to illustrate the point. The x preference 
might for example be the screen font for the desktop; the 
value x«l might call for a default font of Times- Roman. 
Similarly, the default preferences for App4 for all users are 
BG=gray, x=2, y=2 and z=2. 

The default values in the AllUsers group can be modified 
in any desired way for other contexts, such as for other user 
groups and individual users. By way of example, in addition 
to the context of AllUsers in FIG. 3, four other groups 
(GroupX, Group Y, GroupYl and GroupY2) are shown. 
Additionally, two individuals Userl and UserN are shown. 
Users can be members of more than one group. In FIG. 3, 
Userl is a member of AllUsers, GroupX and GroupYl; 
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UsenN is a member of AllUsers and GroupY2. If a user is use the configuration applet to modify the coalesced pref- 

a member of more than one group (another group in addition erences in any desired manner, 
to AllUsers), then the groups are prioritized for the purpose 

of selecting the preferences for a given applet for that user. LXAMFLb 2 

The administrator configures the group priorities for a user. 5 Userl ^quests execution of com.ibm.App3. Preferences 

Group priority is illustrated in FIG. 4. In FIG. 4, Userl has must 06 coalesced for com.ibm.App3 in the context of 

GroupX (identified by the fully qualified name of AllUsers- Userl. 

.GroupX for his or her highest priority group. Userl's next FIG. 4 shows that the highest priority group for Userl is 
highest priority group is GroupYl AllUsers.GroupX; this branch of the group hierarchy will be 
(AllUsers.GroupY.GroupYl). Userl 'slowest priority group 1Q checked first for preference information pertaining to App3. 
is the AllUsers group. When a user, say Userl, requests to From here on, the example is essentially the same as 
run an applet say App3, the preferences are coalesced from example 1 above, except that the coalesced set of prefer- 
the tree of FIG. 3 according to the group or groups to which ences is used to configure App3 on the user's workstation, 
the user belongs and the user applet is configured on the user The preferences for App3 for Userl are: BG-Green, x«l, 
desktop accordingly. 15 y=2, z=3 since the BG=Green preference stored in the Userl 
The first step in coalescing preferences for any context is 's context for App3 over rides the default BG=Blue prefer- 
to get the defaults. The defaults for a user, if there are any, ence obtained from the AllUsers.GroupX branch of the 
is the coalesced set of preferences for the applet from the preference tree, 
highest priority group from which preference information EXAMPLE 3 
for the applet can be obtained. The defaults for a group if 2Q Coalesci pre f eren ces for com.ibm.App6 in the context of 
there are any, is the coalesced set of preferences for the jj^i 

applet from the groups parent (i.e., Tne AllUsers group is the ^ , e aiuslrales , he sjtuatjon of , he hi ^ es , rf _ 

parent of AUUsers.GroupX) If a group has no parent (ix., orj containing no coalesed preferences for the 

the top level AllUsers group), there are no defaults for that ^ ^ Vx[1 . ^ ^ nes( dori for Usefl 

group. To coalesce the preferences for an applet at a context, „ r . „ v , , AM , m , . 

* K - /• . , . • i j 25 is GroupX. This group and its parent AllUsers contain no 

the preferences for the applet explicitly stored at the context, r r a * n-u r *u . u - u « • 

r „ , r . r r t r . preferences for Appo. Therefore, the next highest priority 

overwnte the default preferences for the applet for the jg ^ Mx| M riori for ^ 

context. Thus, to coalesce preferences into the default set for b G Y1 A M of preferences can ^ obtained from this 

an applet in a group context recurs.ve calls are made from f fi The of preferences proceeds „ 

each group node up to the AllUsers group requesting each x descrhed in ex a le L Recuisive aVi are made from 

parents set ot pre lerences lor the applet. Please reter to HO. « V1 t * t . . A11II „ „ A tU 

£ i ^ , . GroupYl up the tree to the root AllUsers group and the 

3 to illustrate the following example. For example, if the e r . # juij .l • n 

. A11 _ - * _y, „ . r ' , preference sets are returned back down the recursive calls 

context ^ AUusers-GroupYGroupYl, a call is made to the ^ modifled ^ tQ form ^ ^ ^ 

parent of GroupYl, which is GroupY, requesting its defaidt ^ ^ ^ modified ^ ^ fcrences stored in 

preferences for the jappkL GroupYl makes a recursive call J5 G yl lQ {Qrm ^ coalesced M of preferences lhat apply 

to its parent, which is AllUsers. AllUsers has no parent, so 4 ... . 4 c . , , . • a am . h . r 

A1 „ T ^ ■ r . , . ., to this context. Stated briefly, Allusers returns a null set of 

AllUsers returns it set of preferences for the applet to the call fcrences> since it has no ' preferences for App6 . GroupY 

from GroupY. Thus set of preferences is mod.fied by the modifies , his nul , ^ wUh ^ values a=1 b=2 ^ 

preferences stored in GroupY for the applet, if any. This is relurns ^ ^ , o yl ^ ^ ^ yl 

now the default set of preferences for the applet for the n modiriesthedefau , tsetw 'i tha0 3. Thissetisrelurnedtolhe 

context of GroupYl. Tins set of default preferences is Usefl fQf ^ ^ dM ^ ^ , here afe Q0 

returned to GroupYl as a result of the recursive call from ferences for A 6 slored at the Userl the 

GroupYl to GroupY and are modified by the preferences at defauUs {mm ^ GroupYl branch of the prefer- 

GroupYl for the applet, if any, to become the actual set of coce ^ K t ^ m M q{ eferences for 

preferences to be used in his instance. The set of preferences Ar A , ™, A _ „, „ f / , , - 

r . , . , v 45 Appo. The real set of preferences thus becomes a=33, b=2 

for the context of a user is budt in the same way, except that ^ tU - ~ . „♦ 

.... .. - ... r • r for this context. 

the highest pnonty group from which preference informa- The above 3 le> described me lherin of ^ 

lion can be obtained for the user is used to firs, establish the ^ fa ^ t{) a ^ fof a icu]ar iece of 

group context from which the debute will be obtained. so£lwa(e ^ fereQce information is saved for a piece 

Then the recurs.ve procedure described above is used to J0 Qf Mfl p re f er ences that have been expliciUy writ- 

buUd the actual set of preferences for the user and the applet teo a( ^ Conleja ^ saved (() wi „ ^ wriUeQ ^ tne ^ 

requested by the user. stofe (212 j a , (he location ^6^6^ by lhe combination of 

The following examples illustrate the above preference ^ Con(exl ^ soflware fa bej mn fa ^ ^ k for lhe 

coalescence and should be read in conjunction with FIG. 3. sof , ware whos6 preferences are being stored . 

EXAMPLE 1 ss Permissions operate similarly: a new group has access to 

An administrator runs a configuration applet for App3 to set all the applet names permitted by the group itself as well as 

preferences for the group AllUsers.GroupX. to all applets permitted by its supergroups. However, just as 

To set the preferences for App3 in the context of Java allows the programmer to override a superclass 

Allusers.GroupX, the present set of preferences must be method, Profile Management allows the System Admin is- 

determined. AllUsers.GroupX requests defaults for its par- 60 trator the ability to override an inherited permission. This is 

ent AllUsers. Since AllUsers is the top level group, it returns called overriding a permission. 

its preferences for App3 to GroupX. These are the default As with Java^ form of inheritance, Profile Management's 

preferences for App3 in the context of GroupX. Since form of preferences and permissions inheritance is called 

GroupX has no preferences for App3, the default set from single inheritance. Single inheritance means that each Pro- 

Allusers is the real set of preferences to be used. In this 65 file Management group can have only one supergroup 

example, these preferences from the AllUsers group are: (although any given supergroup can have multiple 

BG»Blue, x«l, y-2, z-3. The administrator can now modify subgroups). 
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Profile Management users (leafnodes) may require mem- If the configuration applet is registered as a listener to such 

bership in multiple groups, so a facility is required to limit events, profile manager 506 will notify it of a context change 

preference inheritance to a single hierarchical group to via API 516. This allows appletl to refresh its preferences 

minimize the chance of corrupt configurations due to the from the server for each new context. Without the event 

introduction of incompatible variable subsets introduced by 5 listener API, appletl would have to be terminated by the 

cross group branch coalescing. By allowing a user's group administrator and restarted after a new context has been 

memberships to be prioritized, profile management can selected to reference the existing preference information for 

follow a search order when looking for preferences related the new context and avoid being stopped and restarted by the 

to a particular applet. In other words, starting with the group Profile Management applet. To register, appletl calls a 

with the highest priority, the search will stop at the first 10 method on its properties object ProfileManagementProper- 

group found to contain configuration data for the applet ties 510 i.e., add ContextChange Listener (API 516) to reg- 

attempting to load its preferences. ister itself. When the administrator sets a new context, 

A user inherits software permissions from group mem- profile manager 506 performs a set context call (API 516) to 
berships. With careful enterprise modeling, the administra- object 510, which in response calls the reload method (API 
tor can assign software access to many users without having is 516) on event listener 512. Event listener 512 now performs 
to navigate through panels, one user at a time. Profile . a load properties call to its properties object 510 to get the 
management controls access by programming the web new preference data from the server for the new context, and 
server to permit/deny access to applets. The web server causes appletl to updates it GUI and internal variables to 
enforces the access control. The profile manager servlct is reflect the new preference information, 
also protected by the Webserver requiring user ID's and 20 The above functionality avoids the possibility of a net- 
passwords to be passed to the webserver for authentication work administrator reading data from one context, changing 
purposes. It is standard browser functionality to prompt for context, and accidentally overwriting with a save() when 
user passwords as required. intending to load() before making configuration changes in 

FIG. 5 shows the system of FIG. 2 in more detail. the new context. 

Configuration applet Appletl is invoked by the administra- 25 Applets that do not register as listeners will be stopped, 

tor within the profile management framework. Appletl may destroyed, reloaded, and restarted by the profile manager 

implement the application program interface (API) 515 for applet when the adiministrator forces a context change, 

querying information about its operational environment The profile management also provides a "properties 

(e.g., query context, context changed events, query access export" service to allow the easy retrofitting of existing 

control list for this context, etc.) to integrate tightly within 30 hardware and software into this profile management envi- 

the profile management framework, but this is not a require- ronment. The properties export service allows profile man- 

ment for a configuration applet. In any event, the designer of ager 514 to support user workstations (the physical 

appletl need only understand the basic API methods: hardware) as well as users, groups, and user applications. 

enablePersistence(), loadQ, and save() in addition to the Since existing workstations do not know about ProfileMan- 

basic methods of a java.util.Properties object used to get 35 agementProperties 510, the export service allows worksta- 

pre fere nee information into and out of a java.util.Properties tion vendors to create workstation-configuration applets that 

object. API 515 additionally provides list() and getContextO specifies an export agent 520 to be invoked on the server 

methods. Appletl need only register with the ProfileMan- when the vendor applet saves it preference information. The 

agementProperties class and call these methods as appro- export tag causes an instance of a vendor-supplied class (the 

priate. The load() method can be called to retrieve the 40 export agent 520 object) lobe created and the export method 

present state of preferences for the user applet being con- to be invoked on the object to specify that workstation 

figured in the context of a user or group selected by the configuration information be saved in whatever proprietary 

administrator The administrator can then modify the pref- file format and/file location(s) that are required by the 

erences as desired and store them using the configuration workstation being configured. 

save finctionality provided by the applet (which uses the 45 Assume that appletl is the configuration applet provided 

save() method of its ProfileManagementProperties object. by a vendor for an existing terminal that is incompatible with 

Similarly, if appletl needs the list of user applets authorized the present profile management system. The vendor also 

for access by a user, it can use the list() method to obtain the supplies export agent 520. An administrator can configure 

list from the server. The get contextf) method can be used by the terminal for operation in this system by running profile 

the applet to display the name of the context that it is running 50 manager 506, set the context to the terminal being 

in or even to ensure that it only runs in a certain context (i.e., configured, runs the vendor supplied configuration appletl 

if an applet wanted to configure a service on the server using and configures the applet. When the administrator saves the 

the export agent, it might only allow itself to be run at the configuration, part of the information that is transmitted to 

AllUsers context since the configuration being exported is the server is a unique identifier that identifies the terminal 

server specific as opposed to user specific. For appletl to run 55 being configured. Typically, this is the Media Access Control 

in the profile management framework, all that is required is (MAC) address of the terminal. Profile manager servlet 514 

for the applet to register with ProfileManagementProperties detects that an export agent is specified on the save. Profile 

410 and implement the ProfileManagementProperties class, manager servlet 514 detects this from one of the preferences 

an extension of the java.util.Properties class. being saved that specifies need for the export agent. The 

The profile manager 506 also provides a context change 60 preference specifies the export tag in the form of a key value 

API 516 for configuration applets. Appletl may implement pair of 
a context change event listener 512. The API 516 and the 

event listener 512 allows the administrator to change con- xxxXECPORT_AGEt^rxxxx-{fully qualified class name of 

✓ \ ■ •« • *. ■ i export agent} 
texts (user or group) while running the configuration applet, 

without having to slop and restart it. For example, when 65 The Export Agent's export(Context context, config 

configuring applet user preferences, the administrator will properties) method is called by the profile manager servlet 

likely change contexts many times during the configuration. 514 to create one or more files 522 on the server from the 
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save preferences information. The specific file or files are 
identified by the unique identifier of the terminal that came 
with the properties information from applet 1. When the 
terminal later boots up, it uses its unique identifier to locate 
and retrieve its configuration information from files 522 on 
the server in the same manner that it always did, independent 
of the profile management system. 

FIG. 6 illustrates an applet2 running on a client computer. 
Apple t2 might be an end-user applet such as a word pro- 
cessor. In any event, apple t2 has access to some of the the 
same API methods as shown at 515 of FIG. 5 if it desires. 
Apple t2 uses the load method to retrieve preferences and the 
save method to save any preferences that might be changed 
by the end user. En able Persistence initializes the Profile 
Management Properties object for applet2 with context 
equal to the user and generates the unique key for identifying 
the preference information storage location on the server, as 
described above relative to the administrator. 

FIG. 7 shows the situation of a user bringing up his or her 
desktop. The user on the client (700) points his or her web 
browser at the URL of the desktop applet on the server and 
at step 704 sends a message http://server/Desktop.html). 
Since Desktop.html is a file that the server protects, a 
challenge is sent back to the web browser on the client at 
706. The web browser on the client responds by prompting 
the user for a user ID and password. The client then sends 
the user ID and password information to the server at 708. 
The user ID and password are shown in bold at 708 of FIG. 
3 to illustrate that this information is passed by the web 
browser itself. This type of nomenclature is used in other 
places to illustrate the same thing. Since, presumably, the 
user has permission to run the desktop applet, the request 
will be honored. 

There are a series of interactions between the client and 
the server (not shown) where the code for the desktop applet 
is loaded to the client from the server. The desktop object is 
created and begins to execute at 712. The desktop object 
needs its preference information (i.e., configuration 
information) so it can tailor the desktop for the end user who 
is invoking it. To this end, as part of the desktop object's 
initialization process, the desktop creates a ProfileManage- 
mentProperties object P at 714, which is used to load, get, 
cache, set, and save a copy of the user's preference infor- 
mation from the server for the desktop applet. The desktop 
object then performs an API call P.enable Persistence 
(desktopObject (applet)) at 716, which, at step 1) of 716, 
initializes the ProfileManagementProperties object P with 
the URL of the profile manager servlet 214. This URL is 
derived from the URL of the desktop applet that was loaded 
from the server previously. The ProfileManagementProper- 
ties object P sends a request 718 to the profile manager 
servlet 214 to get the context for the user running the 
desktop applet. In this case, the context consists of two 
components, a context name which is the ID of the user, and 
a context type which in this case is User. The profile 
manager servlet gets the ID of the user from the request 718 
and returns the user context at 719. At step 2 of 716, the 
ProfileManagementProperties object P is initialized with the 
context of the user running the desktop. At step 3 of 716, the 
ProfileManagementProperties object P generates a unique 
key for the desktop software by asking the Java desktop 
object P for its fully qualified class name. All Java objects 
know their class name. This unique key is combined with the 
user's context information to provide a parameter that 
specifies a unique location in the database 212 for storing the 
user specific preference information for the desktop applet. 
Any desired method can be used for mapping the string 
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consisting of the fully qualified class name and the user 
context information into the data store location. Next, a 
request 720 is sent to the profile manager servlet 214 to get 
the preference information, tailored for the user, for the 

5 Desktop applet. The context and key are passed as part of the 
request 720 to identify the requested preference information. 
The profile manager servlet 214 responds with the requested 
preference information at 722, which is cached in the 
ProfileManagementProperties object P 604. 

10 Continuing on at FIG. 8, at 800 the Desktop object reads 
it's preference information out of its ProfileManagement- 
Properties object P, and begins to update the desktop accord- 
ingly (i.e., it might set the screen color to blue, get infor- 
mation about the position of icons, etc.). The desktop object 

is calls a method on its ProfileManagementProperties object P 
to get a list of the software to which the user has access 
permission. The ProfileManagmentProperties object P 
requests the information at 802 from the profile manager 
servlet 214, which generates a response with the requested 

20 information at 804. For each such applet to which the user 
has access, the information includes a user friendly name, 
the applet's URL, the URL of an icon for the applet, etc, 
(information that is required for the desktop to represent the 
applet on the desktop and to load and launch it) and other 

25 optional material which is not relevant to the invention. This 
information is stored in the ProfileManagmentProperties 
object P, and returned to the desktop object. At 806, the 
desktop object uses the applet information to build a folder 
for the applets and to generate a window displaying the icons 

30 and the user friendly name for each applet to which the user 
has access. 

Assume that in a previous run of the desktop by the user, 
the user dragged and dropped the icons for some of the 
software displayed in the folder that was just described. It is 

35 possible that at this time the user no longer has access to the 
applets that were dragged and dropped from the folder to the 
desktop. However, these desktop objects normally would be 
a part of the users preferences that were saved during the last 
run and would still be displayed on the desktop . To avoid 

40 this situation, the desktop examines its preferences from it's 
ProfileManagmentProperties object P to check for applets 
that are configured to appear outside of the window that is 
generated to display all applets to which the user has access. 
FIG. 8 assumes that there is only one applet outside of the 

45 applet window that is generated. If there were more than one 
such applet outside of the applet window, the following 
procedure would be looped for each such applet. At step 810 
the desktop checks each of these applets appearing outside 
of the applet window against the list of applets from the 

50 server to which the user has access. If the applet appears in 
the list, the icon for the applet is placed on the desktop at 810 
in the same position as before. If the user no longer has 
access to the applet, the applet is removed from the desk- 
top's preferences at step 814 and removed from the Profile- 

55 ManagmentProperties object P. If any applets are removed 
as part of this process, the desktop tells the ProfileManag- 
mentProperties object P to save the preferences at step 816. 
The ProfileManagmentProperties object P sends a request 
818 with the preference, key, and context information to the 

60 profile manager servlet 214 to save the new preferences 
information in the Database 212. The server sends a 
response 820 to the ProfileManagmentProperties object P 
informing the ProfileManagmentF^roperties object P that the 
request was successfully completed. 

65 FIG. 9 illustrates the situation of an administrator running 
a configuration applet to configure preferences for an applet 
for other users or groups of users. It is understood that the 
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principles discussed here also apply generally to the con- 
figuration of terminals or groups of terminals. The admin- 
istrator on the client 900 points his or her web browser to the 
URL of the profile manager applet 214 on the server, which 
is to be run. The URL is sent to the server at 904. Since 5 
ProfileManager.html is a file that the server protects, a 
challenge 906 is sent back to the web browser on the client. 
The web browser responds by prompting the administrator 
for a user ID and password. The request to get ProfileMan- 
ager.html is then repeated at 908 to the server with the user 10 
ID and password information included in the message. Since 
presumably the administrator has permission to run the 
profile manager, the request is honored and a profile man- 
ager applet is downloaded to the administrators terminal at 
910. There are a series of interactions between the client and is 
the server (not shown) where the code for the profile 
manager applet is loaded to the client from the server. The 
profile manager object is created and begins to execute at 
step 912. 

A ProfileManagementProperties_noncontextFloating is 20 
used by the profile manager instead of a normal ProfileM- 
anagementProperties object. It has the same behavior as a 
ProfileManagementProperties object with one exception: 
when preferences are loaded and saved, they are loaded and 
saved to and from the context of the administrator who is 25 
running the profile manager, as opposed to loading and 
saving to and from the context (i.e., user or user group) for 
which the administrator is configuring. 

The profile manager object needs its preference informa- 
tion (i.e., configuration information) so it can tailor the 30 
profile manager for the administrator is invoicing it. To this 
end, as part of the profile manager object's initialization 
process, the profile manager creates a 
ProfileManagementProperties_nonContextFloating object 
P_NCF at step 914, which is used to load, get, cache, set, 35 
and save a copy of the administrator's preference informa- 
tion from the server for the profile manager applet. The 

profile manager object then calls P NCF.enablePersistence 

(profileManagerObject (applet)), which in step I of 916 
initializes the ProfileManagementProperties_ 40 
nonContextFloating object P_NCF with the URL of the 
profile manager servlet 214. This URL is derived from the 
URL of the profile manager applet. The 
ProfileManagementProperties_nonContextFloating object 
P_NCF sends a request 918 to the profile manager servlet 45 
214 to get the context name (ID) of the administrator and the 
context type (USER). The profile manager servlet gets the 
ID of the administrator from the request (918). The web 
browser passes the administrator ID and password in the 
message along with the information sent by the 50 
ProfileManagementProperties_nonCdntextFloating object 
P_NCF. The ProfileManagementProperties_ 
nonContextFloating object P_NCF is initialized with the 
context of the administrator running the applet at step 2 of 
916. At step 3 of 916, the ProfileManagementProperties_ 55 
nonContextFloating object P_NCF generates a unique key 
for the profile manager applet by asking the Java profileM- 
anagerObject object (passed as a parameter in the enablep- 
crs isle rice call) for its fully qualified class name (i.e., 
profile ManagerObject.getClassO-gelNameO). This unique 60 
key, combined with the administrator's context information, 
is mapped to specify a unique location in the database 212 
for the administrator's specific preference information for 
the profile manager applet. 

A request (922) is sent- to the profile manager servlet 214 65 
to get the preference information tailored for the profile 
manager applet as configured for the administrator. The 



request (922) includes the appropriate context name and 
type and key information to identify the appropriate prefer- 
ence information. The profile manager servlet 214 responds 
with the requested preference information (924), which is 
cached in the ProfileManagementProperties_ 
nonContextFloating object P_NCF. The profile manager 
reads its preference information out of the 
ProfileManagementProperties_nonContextFloating and 
updates itself accordingly (i.e., sets its background color to 
blue for example). 

Operation continues at FIG. 10. The profile manager 
requests the information about existing users, user groups, 
and software from the profile manager servlet 214 and builds 
the tree in the left panel of the profile managers configura- 
tion window at 1002. See FIGS. 13 through 24 for examples 
of the administrator's left panel. At this point 1004, the 
administrator selects a desired context for configuring by 
clicking on a user or group from the left panel tree. The 
profile manager sets the context for ProfileManagement- 
Properties objects by calling P_NCF.setContext(selected 
context). See FIG. 13 for a selected context of "User 
Groups", which refers to the group of all system users, or to 
FIG. 18, where a group context of "Development" is 
selected, or to FIG. 21 where a user context "colleend" is 
selected. Next, at step 1006, the administrator selects an 
applet to be configured from a list of all the applets on the 
server. See FIG. 17 for an example of selecting an applet. At 
step 1008, the administrator then clicks a Run/Customize 
button to run the applet selected for configuration. This 
applet might be a separate configuration applet for an end 
user applet, or it might be the end user applet itself. The 
selected applet is requested and loaded from the Server at 
1009 and 1011. At step 1010, the configuration applet object 
is created and begins to execute and to generate its Profile- 
ManagementProperties object P. 

If it is assumed that the applet is a separate configuration 
applet for an end user applet, then at step 1012, the applet 
calls p. enablePersistence(con fig Applet Object, 
fullyQualifiedClassNameOfAppletBeingConfigured). On 
the other hand, if the applet is a user applet, rather than a 
separate configuration applet, the call would be 
p. enable Persistence(endUserAppletObject) since it wants to 
configure its own preference information as opposed to the 
preference information for another applet. The current Con- 
text is already known by the ProfileManagementProperties 
object P since it was previously set by the administrator via 
the administrator's ProfileManagementProperties__ 
nonContextFloating object PM_NCF. The location of the 
profile manager servlet 214 was previously generated when 
enable Persistence was called on the Profile Managers 
Profile ManagementProperties_nonContextFloating object 
PM_NCF. In the case of a configuration applet, the unique 
key for the applet does not need to be generated because it 
is passed by the configuration applet to the ProfileManage- 
mentProperties object P in the enablePersistence call. 

At step 1014, the configuration applet registers itself with 
its ProfileManagementProperties object P as a context 
change listener. As discussed earlier, this allows the applet's 
ProfileManagentProperties object P to notify the applet if the 
administrator makes a context change so that the applet can 
load the preference information for the new context and 
update its Graphical User Interface to reflect the new con- 
figuration information, without requiring that the applet be 
terminated and relaunched in the new context. 

Operation continues at FIG. 11. At step 1104, the con- 
figuration applet tells the ProfileManagementProperties 
object P to load the preferences from the current context for 
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the applet being configured. A request 1105 is sent to the 
profile manager servlet 214 to get the preference 
information, tailored for the context previously selected by 
the administrator, for the applet being configured. The 
request 1105 includes the appropriate context name (the 
context the administrator has selected) and the context type 
(USER, USER_GROUP, or ALL_USERS_GROUP as 
appropriate) and key information to specify the location of 
the appropriate preference information. The profile manager 
servlet 214 responds with the requested preference informa- 
tion at 1106, which is cached in the ProfileManagement- 
Properties object P. The configuration applet gets prefer- 
ences from the ProfileManagementProperties object P and 
updates its Graphical User Interface accordingly. 

The administrator configures the applet at 1107 and saves 
the modified preferences, for example by clicking a SAVE 
button provided by the applet. As a result of this operation, 
the configuration applet calls the saveQ method on its 
ProfileManagementProperties object p. The ProfileManage- 
mentProperties object P sends the preferences and the 
unique key for the applet being configured and the infor- 
mation specifying the current context to the profile manager 
servlet 214. The profile manager servlet stores the prefer- 
ence information in the database 212 in the location speci- 
fied by the Context and the key. 

Step 1108 is an example of the administrator now chang- 
ing context, while the configuration applet is still running. 
The administrator selects a new context by clicking on a user 
or user group (see FIG. 18 for examples of new contexts in 
the administrators left screen panel). As a result of the 
context change, profile manager 506 sends a set context 
message to ProfileMangementProperties object P (510) by 
calling P_NCF.setContext(selected NEW context), which 
in turn causes object P to notify event listener 512 of the 
context change via the reload properties API 515. This 
occurs at step 1110. At step 1112, the event listener 512 
performs a load() call to retrieve the preferences for the new 
context and the object P is updated with the new preferences 
at step 1118. The administrator can now proceed to modify 
the new preferences for the new context, if desired, and to 
save them if required, and then to proceed on with a new 
context change if necessary as described above. 

The remaining FIGS. 12 through 24 show actual screen 
snapshots of an administrator's workstation while running 
portions of the profile manager 206. 

The main configuration window 1200 is shown in FIG. 
12. The tree view panel 1202 on the left of the window 
depicts profile management 1204 as one of several services 
available on the server. When this item 1204 is selected as 
shown in FIG. 12, the right panel 1205 of the main window 
displays a welcome message for the profile management 
service. Expand and contract icons such as 1208 are used to 
control the appearance of sub-items under an item in the left 
panel, if any exist. The in 1208 is called an "expand 
icon" and indicates that there are sub-items beneath "Profile 
management". The administrator can display these sub- 
items by clicking on the expand icon 1208, which will then 
become a "contract icon" ("-"). 

FIG. 13 illustrates an expansion of the Profile manage- 
ment item 1208 in FIG. 12, which results in the display of 
three default sub-items in FIG. 13— "Applets" 1300, "User 
Groups" 1302 and "Users" 1304. Expansion icons indicate 
that these items can also be expanded. "Applets" 1300 
allows the administrator to define the user applets available 
on server 202, "User groups" 1302 allows the administrator 
to create and populate the user group tree of FIG. 3 and to 
set group preferences. "Users" 1304 allows the administra- 
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tor to create new users and to set their preferences or to 
change preferences for existing users. In the example of 
FIG. 13 "Applets" 1300 is selected. When this item is 
selected, panel 1305 on the right of the window displays a 
list 1306 of user applets that have already been defined to the 
system. Attributes of the application that is selected in 1306 
are shown at 1308. The administrator defines a new applet 
by selecting <NEW> in 1306 and entering the name and 
location information requested in 1308. An existing applet 
"Database Explore r" is shown selected in 1306. At 1308, the 
"Applet name" field displays this applet name. The "URL" 
(Universal Resource Locator) field displays the Intranet or 
Internet web address of this applet on server 202. The field 
"Complete path of html file" displays the directory path and 
file name of the applet in the disk directory structure of 
server 202. The field "Fully qualified class name" displays 
the fully qualified class name of the applet. The field "Icon 
URL" displays a web address of the image file used to 
generate an icon for the applet on a users desktop. The 
remaining fields are for optional information that may be 
required by the software upon invocation. A command 
button 1310, "Import Applet List from File", allows the 
administrator to append definitions of applets to the existing 
list 1306 from an existing text file. When button 1310 is 
clicked, the window shown in FIG. 14 pops-up and allows 
the administrator to enter the path and file name of the text 
file containing the applet definitions to be appended. To save 
all pending changes, the administrator clicks on File 1312 
and then Save (not shown). 

In the left panel, the User Groups item 1302 corresponds 
to the AllUsers group of FIG. 3 ("User Groups" and "AllUs- 
ers" are used interchangeably herein). FIG. 15 shows the 
right panel of the administrators station when the "User 
Groups" item 1302 is selected. In FIG. 15, a notebook panel 
is displayed on the right that contains three tabs — a Mem- 
bers tab 1514, a Subgroups tab 1516 and an Applet Permis- 
sions tab 1518. The Members tab is selected in FIG. 15. The 
Members panel contains a list 1520 of the log-on identifi- 
cations of all members thai have been defined to the system. 
To create a new user (who will automatically gain member- 
ship into the presently selected group context — "User 
Group"), the administrator selects <NEW> from the list 
1520, enters the appropriate information in the entry fields 
1522 to the right of the list, and then clicks on the Create 
button 1522. When an existing member is selected from the 
list 1520, the attributes previously saved for that user are 
displayed at 1522. These attributes include the full name of 
the selected member, the member's system ID, password 
and any desired comments. The attributes, except ID, may 
be edited and the changes committed (but not Saved) by 
clicking the Modify button 1524, or the user may be 
removed from the system entirely by clicking the Delete 
button 1526. Any pending change may be removed by 
selecting the entry in the list 1520 and clicking the Undo 
button 1528. 

FIG. 16 shows the administrator's right panel that is 
displayed when the Subgroups tab 1516 is selected. Sub- 
group list 1620 shows existing groups that are subgroups of 
the item selected in the left panel, which is "User Group" in 
this example. Therefore, list 1620 displays all immediate 
subgroups of the "AllUsers" group. In the left panel, "User 
Groups" is expanded. The subgroups shown in list 1620 are 
also the expanded items under "User Groups" in left panel. 
In list 1620, a status field shows the present status of each 
subgroup, such as "! delete", "! Modify", and "! Create". An 
empty Status field in list 1620 indicates that the subgroup 
exists and no actions are pending to be saved. The "!" 
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symbol indicates that the status is pending (not yet saved). 
Attributes for the subgroup selected in list 1620 appear in 
1622. These attributes include the subgroup name and 
desired comments about the subgroup. To create a new 
subgroup, the administrator selects <NEW> from list 1620, 5 
enters the subgroup name and desired comments in 1622, 
and clicks the Create button 1628. An entry of "! create 
<subgroup name>" then appears in list 1620 as a pending 
action. To save all pending changes, the administrator clicks 
the File button in the top menu bar and then Save (not 10 
shown). 

FIG. 17 shows the right panel that is displayed when the 
Applet Permissions tab 1518 is selected. List 1720 shows all 
names of all applets that have been defined to the system and 15 
the permission status (permit or deny access) that is assigned 
to each applet for the group or subgroup (the current 
"context") that is selected in the left panel. As with other 
notebook pages described, an exclamation point indicates 
that the status depicted is a change that is pending a Save. 20 
In FIG. 17, the group "User Groups" is selected in the tree 
shown in the left panel, which corresponds to the "AllUsers" 
group shown in FIG. 3. Since all users of the system have 
membership in the "User Groups" group, list 1720 shows the 
global default permissions for all system users for each 25 
applet defined to the system. For example, the default 
permission status for applet "Database Explorer" is "permit" 
(meaning access is permitted) for the "AllUsers" group; 
similarly, the default permission status for all users to applet 3Q 
TFTP is "deny" (access is denied). The administrator can 
change the permission status of an applet by selecting it in 
list 1720 and clicking the "Permit group access" button 1730 
or the "Deny group access" button 1732. Furthermore, 
regardless of an applet's permission status for the selected 35 
context, an administrator can select an applet from 1720 and 
click the "Run/Customize" button 1734 to execute the user 
applet under the selected context. The panel region previ- 
ously showing the notebook for the current context then 
becomes occupied by the executing user applet. If the user 40 
applet happens to be a configuration applet for other 
software, the administrator can then save software prefer- 
ences (through the configuration applets unique facilities 
provided for this function) which will then be saved as the 
software's default preferences for the selected context. If the 45 
applet is an end user applet, the functions are the same, 
except the end user applet loads and saves it own preferences 
rather than preferences for a separate piece of software. 

FIG. 18 shows the complete expansion of the adminis- 
trators left panel subgroup tree beneath "User Groups", so 
Immediately beneath "User Groups", there are two sub- 
groups "Administrators", a default subgroup that cannot be 
removed, and "IBM", a subgroup defined by the adminis- 
trator. The "IBM" subgroup has also been expanded and 
contains three subgroups "Hardware", "Services" and "Soft- 55 
ware". The "Software" subgroup has been expanded and 
contains at least one subgroup called "Development". The 
"Development" subgroup contains at least one subgroup 
called NCoD. Subgroup "NCoD" contains a number of 
subgroups, such as ConfigFW 58, which have no children. 60 
Also in this example, subgroup "Development" is selected 
in the expansion tree. Since "Development" is not at the top 
of the tree hierarchy (the "All Users" group), the notebook 
shown in the right panel is somewhat different from that of 
FIG. 15 when "User Groups" was selected, because all users 65 
are not automatically a member of "Development", as they 
are of "User Groups". The list 1820 displays the log-on 



,476 Bl 

20 

system IDs of all system members. The status beside each 
user ID in list 1820 shows whether the user owns a mem- 
bership in the "Development" subgroup. A status of "yes" 
indicates that the user is a member of the "Development" 
subgroup, "no" indicates that the user is not a member of the 
"Development" subgroup, and "inherited" indicates that the 
user inherits membership within the "Development" group 
by belonging to at least one of Development's subgroups 
further down the tree. A user's membership status for a 
subgroup is modified by the administrator by selecting the 
user in list 1820 and then clicking on the "Add to Group" 
button 1836 or "Remove from group" button 1838, If the 
administrator wishes to create a new system user, or modify 
or delete an existing member, the administrator clicks on the 
"Create/Modify/Delete Users" button button 1840. This 
action brings up the notebook page shown in FIG. 19. The 
right panel of FIG. 19 is similar to that of FIG. 15 and allows 
the administrator to create a new system user by selecting 
NEW in list 1920 and then clicking the "Create" button. 
Similarly, the administrator can modify or delete an existing 
system user by selecting the appropriate user in list 1920 and 
clicking the appropriate button "Modify" or "Delete". Users 
created at any subgroup context (e.g., "Development") not 
only gain the required membership in "User Groups", but 
are automatically made members of the selected subgroup. 
Changes to the system user list are saved by clicking on 
"File" in the top menu bar of the right panel and then 
clicking "Save" (not shown). 

FIG. 20 shows a direct way to get to the system user list 
for editing, rather than through the group and subgroup route 
shown in FIG. 19. To get to FIG. 20, the administrator 
selects "Users" 1304 in the left panel of FIG. 13, for 
example. Then in the right panel shown in FIG. 20, the 
administrator can create new users and modify and delete 
existing users, as already discussed, without being in the 
context of a group or subgroup. 

In FIG. 21, the administrator wishes to work directly on 
information corresponding to a user whose ID is "colleend". 
To do this the administrator expands "Users" in the left panel 
of FIG. 21, for example, and then selects "colleend", as 
shown. The right panel then appears, which is devoted to 
colleend's system information. The right panel contains 
three tabs. The first tab "User Information" is selected by 
default. In this tab, the administrator can modify the name, 
ID, password and comments pertaining to colleend. 

FIG. 22 shows the right panel when the administrator 
selects the second tab "Group Memberships". List 2220 
shows all subgroups of which colleend is a member. The 
subgroups are shown in this list in the order of subgroup 
priority for colleend. The administrator can change col- 
leend's subgroup priority by selecting a subgroup and using 
the up and down arrows to the right of list 2220 to move the 
selected subgroup up or down the list as desired. If the 
administrator clicks the "Add/Remode Group Member- 
ships" button 2242 in FIG. 22, the right panel then shows the 
contents of FIG. 23. The FIG. 23 right panel allows the 
administrator to modify the subgroups of which colleend is 
a member. The administrator does this by clicking on an 
appropriate box corresponding to a desired subgroup. If the 
box is clear (meaning that colleend is not presently a 
member), then a check mark is added to the box to include 
colleend in the subgroup. Conversely, if a subgroup box is 
already checked, then clicking on the box clears the check 
mark and removes colleend from the subgroup. 

FIG. 24 shows the right panel when the Applet Permis- 
sions tab of FIG. 22 is selected by the administrator. In this 
right panel, list 2420 displays all applets that are defined in 
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the system. The administrator can permit access by colleend 
to an applet by selecting the applet in list 2420 and then 
clicking the "Permit user access" button 2430; or access can 
be denied to colleend by clicking the "Deny user access 
button" 2432. The administrator can also launch an applet in 5 
the context of colleend by clicking the "Run/Customize" 
button 2434. When this is done, the applet selected in list 
2420 is launched in the right panel. The administrator can 
then modify any preferences that the applet allows and save 
the preferences in the manner provided by the applet. A 3Q 
typical scenario here is for the administrator to launch a 
configuration applet then to fill in a variety of preference 
fields. However, if a separate configuration is not provided 
for a user applet, the administrator can launch the user applet 
in the context of a user and set preferences from the user 
applet. A typical scenario here is for the administrator to 
select a group or user context and then to launch the user 
applet as described above. The administrator can then typi- 
cally modify preferences from an options menu and save 
them in any manner provided by the user applet. For 
example, typically, the user preferences are saved when the 
options dialogue is closed, or the user applet may provide 
other methods of saving the preferences. In any event, since 
the administrator is running the applet in the context of 
colleend in this example, the preferences set up by the 
administrator through the user applet are saved on the server 
as if colleend had entered them directly herself by running 
the applet. 

Not shown in the figures is a scenario whereby a user can 
modify some preferences that pertain to a user applet. For 
example, a user applet may allow a user to select a window 
background color or fonts and font sizes, so that each system 
user can individualize the applet to some extent when the 
user applet executes on the users desktop. In this case, the 
user modified preferences are saved in the same way as they 35 
are when the administrator runs the user applet. One 
difference, however, is that the administrator can run user 
applets to set preferences in group contexts, whereas users 
can only affect preferences for their individual context. 

It is to be understood that the above described arrange- 
ments are merely illustrative of the application of principles 
of the invention and that other arrangements may be devised 
by workers skilled in the art without departing from the spirit 
and scope of the invention, ease 

What is claimed is: 

45 

1. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, a method of 
managing user configuration preferences for applications 
executing at a user station, said method comprising 

providing a profile manager at an administrators station, 5Q 

arranging the profile manager to execute a separate con- 
figuration application for a first end user application, 
whereby the administrator can specify configuration 
preferences for the first end user application in the 
context of different groups of system users, 55 

storing the configuration preferences for the first end user 
application on the server, 

arranging the profile manager to execute an end user 
application in the context of different groups of users 
for the purpose of specifying configuration preferences 60 
for the end user application in the context of different 
groups executing the second end user application at the 
administrator's station, and 

storing the configuration preferences for the second end 
user application on the server. 65 

2. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, a method of 



managing user configuration preferences for applications 
executing at a user station, said method comprising 

executing a profile manager at an administrators station, 
said profile manager displaying on a display device at 
the administrator's station of a tree of groups of users, 

responsive to a selection of a group on the monitor, 
displaying on the monitor a list of applications known 
to the server and the access permission status pertaining 
to each application in the context of the selected group, 
wherein each application can be a separate configura- 
tion application for a corresponding user application or 
a user application, 

responsive to a request to execute a selected configuration 
or user application, executing the application at the 
administrator's station and establishing a context for 
the executing application as that of the selected group, 
a configuration application providing a facility allow- 
ing the administrator to set configuration preferences 
for the user application corresponding to the configu- 
ration application and a user application providing a 
facility allowing the administrator to set configuration 
preferences for the user application, and 

responsive to a request from the administrator, saving on 
the server the preferences established by the adminis- 
trator for the user application, including saving in 
association with the preferences the group context 
selected by the administrator. 

3. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, an arrange- 
ment for managing user configuration preferences for appli- 
cations executing at a user station, comprising 

a profile manager at an administrators station, including 
means for executing a separate configuration applica- 
tion for a first end user application and means for 
executing a second end user application, whereby the 
administrator can specify configuration preferences for 
the first and second end user applications in the context 
of different groups of system users by executing the 
second end user application, and 

means for storing the configuration preferences for the 
first and second end user applications on the server. 

4. In a network system comprising a network intercon- 
necting a server and a plurality of user stations, a method of 
managing user configuration preferences for applications 
executing at a user station, said method comprising 

providing a profile manager at an administrators station, 

arranging the profile manager to execute an end user 
application in the context of different groups of users 
for the purpose of specifying configuration preferences 
for the end user application in the context of different 
groups by executing the end user application at the 
administrator's station, 

storing the configuration preferences for the end user 
application on the server, and 

downloading a set of preferences stored for a given 
context to a workstation when requested by a user in 
that context. 

5. For use in a network system comprising a network 
interconnecting a server and a plurality of user stations, 
apparatus for managing user configuration preferences for 
applications executing at a user station, comprising 

a profile manager at an administrators station, 
means in the profile manager for executing an end user 
application in the context of different groups of users 
for the purpose of specifying configuration preferences 
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for the end user application in the context of different 

groups by executing the end user application at the 
, administrator's station, 
storing the configuration preferences for the end user 

application on the server, and 
downloading a set of preferences stored for a given 

context to a workstation when requested by a user in 

that context. 

6. A computer program product consisting of a storage 
medium storing computer instructions for generating and 
managing user configuration preferences for end user appli- 
cations in a network, said instructions comprising 
a profile manager for use at an administrators station, 
a first code segment in the profile manager to execute an 
end user application in the context of different groups 
of users, 

a second code segment in the profile manager allowing an 
administrator to execute the end user application in the 
context of a group in order to specify configuration 
preferences for the end user application in a context of 
the group, 

a third code segment for storing the configuration pref- 
erences for the end user application on the server, and 
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a fourth code segment for downloading a set of prefer- 
ences stored for a given context to a workstation when 
requested by a user in that context. 
7. A carrier wave embodying a computer program product 
of computer instructions for generating and managing user 
configuration preferences for end user applications in a 
network, said instructions comprising 

a profile manager for use at an administrators station, 
a first code segment in the profile manager to execute an 
end user application in the context of different groups 
of users, 

a second code segment in the profile manager allowing an 
administrator to execute the end user application in the 
context of a group in order to specify configuration 
preferences for the end user application in a context of 
the group, 

a third code segment for storing the configuration pref- 
erences for the end user application on the server, and 

a fourth code segment for downloading a set of prefer- 
ences stored for a given context to a workstation when 
requested by a user in that context. 
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